Skip to content

Fix HUD CPU usage: measure /proc/stat load instead of clock-frequency#614

Draft
Xnick417x wants to merge 6 commits into
WinNative-Emu:mainfrom
Xnick417x:cpu-p
Draft

Fix HUD CPU usage: measure /proc/stat load instead of clock-frequency#614
Xnick417x wants to merge 6 commits into
WinNative-Emu:mainfrom
Xnick417x:cpu-p

Conversation

@Xnick417x

Copy link
Copy Markdown
Collaborator

Compute CPU% from /proc/stat busy vs idle jiffie deltas (on-screen HUD and Task Manager pane, aggregate and per-core) instead of scaling_cur_freq/max which does not reflect actual utilization. Add Mali GPU load fallbacks (/sys/kernel/gpu/gpu_busy, /proc/mtk_mali/utilization).

… ratio

Compute CPU% from /proc/stat busy vs idle jiffie deltas (on-screen HUD and
Task Manager pane, aggregate and per-core) instead of scaling_cur_freq/max
which does not reflect actual utilization. Add Mali GPU load fallbacks
(/sys/kernel/gpu/gpu_busy, /proc/mtk_mali/utilization).
Poll the second CPU sample after 500ms during warm-up (then settle to 1s) and
force a redraw when the first real value lands, so the on-screen HUD stops
showing CPU N/A within about half a second instead of a full second. Reset the
previous sample when stats start so re-showing the HUD no longer reports a delta
spanning the hidden period.
@Xnick417x Xnick417x marked this pull request as draft July 12, 2026 01:12
On devices where the app cannot read /proc/stat, the delta sampler returned no
data and the HUD showed CPU N/A. Try /proc/stat first (accurate) and fall back
to the clock-frequency estimate so a value always shows, on both the on-screen
HUD and the Task Manager pane.
The kgsl gpubusy counter reads busy=0 total=0 at idle; dividing by total==0
fell through to the read-failure path and showed N/A. Return 0 for that case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant